home *** CD-ROM | disk | FTP | other *** search
/ Super Shareware Collection / Super Shareware Collection.iso / info / chicqa.zip / CHICQA.TXT < prev   
Text File  |  1994-02-12  |  39KB  |  519 lines
  1. DECEMBER 1993 
  2.  
  3. Chicago Questions and Answers 
  4. Microsoft is continually enhancing its Windows operating system product line to deliver easy 
  5. to use yet powerful products that exploit the latest advances in microcomputer hardware 
  6. technology.  There is a great deal of interest in and speculation about the ôChicagoö project, 
  7. the technology development effort which will deliver the next major release of Windows for 
  8. the mainstream desktop and portable PC.  The purpose of this document is to answer the 
  9. most common questions that customers have voiced about Chicago. 
  10.  
  11.  
  12. *    What is Chicago and how does it compare to the Microsoft* Windows* 3.1, Windows* 
  13. for Workgroups and Windows NT* operating systems? 
  14. Microsoft has a family of operating system products designed to fully utilize the range of PC 
  15. hardware available in the market today, while providing a consistent user interface for end 
  16. users and a programming environment for developers.  Windows 3.x and Windows for 
  17. Workgroups 3.x on MS-DOS* are designed for mainstream portable and desktop PC 
  18. platforms.  Windows NT is designed for the high-end business and technical workstation 
  19. platforms and Windows NT Advanced Server is designed as a server platform. 
  20. Chicago is the code name for a development project that will produce the successor to 
  21. Windows 3.x and Windows for Workgroups 3.x.  The Chicago project encompasses a 
  22. variety of important new technologies that will make personal computers running Windows 
  23. easy to use, and that will provide a more powerful multitasking system and a great platform 
  24. for communications.  Decisions about how those technologies will be packaged will be made 
  25. later in the development cycle and will be based on customer and business needs. 
  26. *    What is Cairo?  How does Chicago compare to Cairo? 
  27. Cairo is the code name for a development project that will produce the successor to Windows 
  28. NT.  Chicago and Cairo will produce complementary products that will continue to provide a 
  29. consistent user interface and programming environment across the entire range of PC hardware 
  30. platforms. 
  31.  
  32.  
  33. *    Why does Microsoft have multiple Windows operating system products?  WouldnÆt it be 
  34. simpler to just have one product?  Does that mean ISVs have to decide between different 
  35. operating system products when writing applications? 
  36. There are two distinct design points for operating systems platforms.  One is centered on the 
  37. mainstream system, and the other is centered on the high-end system.  It is not possible to 
  38. have one operating system implementation that fully exploits the broad range of hardware 
  39. available today.  At the low end (currently represented by products such as the HP Omnibook 
  40. and entry-level desktop machines), the primary design goal is to keep the operating system 
  41. small and fast and to keep usage of machine resources to a minimum.  At the high end (for 
  42. example, a dual-processor technical workstation), the product would need to fully support 
  43. multiprocessing and advanced 3-D graphics as well as be capable of running technical 
  44. applications that use maximum machine and system resources.    
  45. Over time, low-end machines will become more powerful, and over time, some of todayÆs 
  46. high-end features will migrate to the low end.  In addition, some technical innovations will 
  47. appear on the mainstream Windows system first, largely because of the timing of product 
  48. releases, and because some features are focused on end users and ease of use.  The Win32 
  49. API assures developers that, whichever system they target today, their applications will be 
  50. able to run in the future as the platform evolves.   Thus, while Chicago and Cairo may 
  51. leapfrog one another with some features, depending on release cycles ù e.g., Chicago will 
  52. sport the next major advance in the user interface, with Cairo inheriting it in its release a few 
  53. months later ù the general principle over time is that the high-end product will be a 
  54. superset of the functionality offered in the mainstream product.  Any deviations from this 
  55. principle are temporary, due to variations in the product release schedules. 
  56. For ISVs and for development purposes, however, Microsoft has just one Windows platform, 
  57. defined by the Windows-based 32-bit API, Win32.  By following a few simple guidelines, 
  58. ISVs can write a single application (executable) that runs on the Windows operating system 
  59. product family.  If they wish, ISVs can target specific operating system products because 
  60. the functionality they provide is important to their particular application, but that is not a 
  61. requirement.   
  62. This situation is very much like the Intel* microprocessor product line.  At any point in time, 
  63. the Intel product line offers multiple products targeted toward different PC products, ranging 
  64. from the 80386SL for low-end portable products to the Pentium* microprocessor for high-end 
  65. workstations and application servers.  What defines those products is the Intel instruction set, 
  66. which enables applications to run on all Intel chips, even though the underlying implementation 
  67. at the transistor level may be very different across the Intel product line.  There are also some 
  68. instructions offered on the Pentium chip that are not on the 80386SL, but ISVs would have to 
  69. go out of their way to make their products run on only Pentium.  And over time, Pentium will 
  70. become more mainstream, just as the 80486 has become the mainstream microprocessor 
  71. today, and technologies developed at the low end, such as System Management Mode, will be 
  72. implemented on the high end as well. 
  73. *    When will Chicago ship?  When will Cairo ship? 
  74. Chicago is scheduled to ship in the second half of 1994.  Cairo is scheduled to be released 
  75. in the first half of 1995. 
  76.  
  77.  
  78. *    What is Daytona?  When will it ship?   
  79. Daytona is an interim release of Windows NT that is scheduled to ship this spring. 
  80. *    Major new releases of operating system products have in the past been significantly delayed.  
  81. How will you make your projected shipment date for Chicago? 
  82. Chicago will be released when customers tell us it is ready.  The way to make shipment 
  83. dates is to hit your intermediate milestones.  To date, Chicago has been making its 
  84. milestones with the release of the first Preliminary DeveloperÆs Kit (PDK) in August and the 
  85. second PDK in December.  Feedback from beta releases beginning in March will tell us more 
  86. precisely when in the second half of 1994 Chicago will ship. 
  87. *    If Chicago ships before Cairo, how will users of Windows NT obtain the new functionality in 
  88. Chicago? 
  89. Any new functionality offered in Chicago will be made available to customers of Windows 
  90. NT through the release of the Cairo product. 
  91.  
  92. *    What are the key benefits and features of Chicago?  What features will Chicago not have? 
  93. For customers, Chicago will present a major step forward in functionality on mainstream desktop 
  94. platforms by providing a system that is easy to use, offers responsive multitasking performance, 
  95. and provides a great platform for communications.  Ease of use will be delivered through the 
  96. Plug and Play architecture and an improved, intuitive user interface.  Chicago will be a complete, 
  97. integrated protect-mode operating system that does not require or use a separate version of MS-
  98. DOS, implements the Win32* API, and provides pre-emptive multitasking and multiple threads 
  99. of execution for 32-bit applications.  The communications capabilities of Windows will be 
  100. enhanced with integrated, high-performance networking, built-in messaging, and features such 
  101. as Remote Network Access and File Synchronization designed for mobile and remote computer 
  102. users. 
  103. Chicago will also be a hassle-free upgrade for the current installed base of Windows-based users.  
  104. Chicago will be compatible with most current applications and drivers for MS-DOS and Windows, 
  105. and will provide an easy transition to the new user interface features.  The applications 
  106. performance of Chicago will meet or exceed the performance of Windows 3.1 on 80386 
  107. systems with 4MB of RAM running the same applications.  For systems with more memory, 
  108. performance will be significantly improved over Windows 3.1.  The setup program will enable 
  109. customers to uninstall Chicago, assuring customers a way to remove it if they are in any way 
  110. unhappy with it, and will provide tools for system administrators to customize the configuration 
  111. of Chicago. 
  112. Chicago will not be processor independent, nor will it support symmetric multiprocessing 
  113. systems, provide C2-level security, or provide full Unicode support.  These features cannot be 
  114. delivered on the mainstream platform in the near future while still meeting the performance and 
  115. resource targets necessary to create a compelling upgrade for the huge installed base of users 
  116. of the Windows operating system.  If these features are important to a customer, Windows NT 
  117. is the product to deploy. 
  118.  
  119.  
  120. *    What different packages will you have for Chicago? 
  121. Decisions about packaging the different technologies being developed as part of the Chicago 
  122. project will be made later in the development cycle and will be based on customer and 
  123. business needs.  One option is to provide a base Chicago package with some add-on 
  124. packages that deliver functionality required by specific market segments.  This is much like 
  125. the situation today in which the user of Windows 3.1 can upgrade to Windows for 
  126. Workgroups by acquiring the add-on package that adds the 32-bit file system and 32-bit 
  127. networking enhancements to Windows. 
  128. *    Since the term Chicago is a code name, what will you call the product(s) that you will 
  129. eventually release? 
  130. Decisions about names will be made after we decide on a packaging plan. 
  131. *    What will happen to the MS-DOS product line? 
  132. Microsoft will continue to enhance MS-DOS as long as customers require it.  Future versions 
  133. will be derived from the protected-mode technology developed in the Chicago project.  
  134. Current 
  135. MS-DOSûbased applications and drivers will continue to be compatible with new versions of 
  136. MS-DOS. 
  137.  
  138. *    Your performance goals on 4MB platforms sound very ambitious, considering all the 
  139. functionality youÆre adding to Chicago.  How will you achieve those goals? 
  140. Chicago will implement new working set management technologies that will optimize the use 
  141. of memory on low-configuration systems.  The networking, disk and paging caches will be 
  142. fully integrated.  Protect-mode device drivers will be dynamically loadable, to ensure that 
  143. only the drivers that are immediately needed are consuming memory.  More components of 
  144. the base operating system will be pageable.  Great attention will be paid to effective page 
  145. tuning, including hand-tuning source code. 
  146. *    Will Chicago run my current Windows-based applications?  How about MS-DOSûbased 
  147. applications? 
  148. Chicago will run most of the current applications for Windows and MS-DOS, as well as new 
  149. applications written to the Win32 API.  Some classes of applications will need to be revised 
  150. to be compatible with Chicago, such as shell-replacement utilities and file-management 
  151. utilities.  ChicagoÆs new shell provides a complete set of services that is tightly integrated 
  152. with the operating system components.  Shell programs will need to do more than simply 
  153. replace components such as Program Manager or File Manager.  And file-management utility 
  154. vendors will want to revise their applications to take advantage of the Long File Name 
  155. feature that Chicago offers.  Microsoft is working closely with shell-replacement and file-
  156. utility vendors to enable them to revise their products to add value to and be compatible 
  157. with Chicago. 
  158.  
  159.  
  160. *    Will I have to get new device drivers to use my current devices with Chicago? 
  161. Chicago supports current real-mode device drivers as well as new 32-bit protected mode 
  162. device drivers.  As a result, customers will be able to use their current devices either with 
  163. their current device drivers, or with new device drivers made available with Chicago.  
  164. Performance and functionality can be improved if the user installs the new Chicago drivers.  
  165. Microsoft is making it easier for device manufacturers to deliver new drivers for common 
  166. devices by defining a more layered, modular device driver architecture.  For displays, printers 
  167. and modems, Microsoft will deliver universal drivers.  These drivers will implement common 
  168. device functionality and expose an interface for device manufacturers to create ôminidriversö 
  169. that implement the features specific to their devices.  This approach was very successful 
  170. with printers for Windows 3.1, resulting in rapid availability of fast, high-quality drivers for a 
  171. wide range of printers. 
  172. *    Will my current applications perform as well on Chicago as they do on Windows 3.1 today? 
  173. For Chicago to be a compelling upgrade, Windows-based users must experience a level of 
  174. performance after installing Chicago that meets or exceeds the performance they currently 
  175. experience running an identical set of tasks on Windows 3.1.  Because a large portion of the 
  176. installed base of users of Windows today have 4MB systems, Chicago must meet its 
  177. performance goals on 4MB systems.  On systems with more than 4MB of RAM, Chicago will 
  178. offer significantly improved performance. 
  179. Understand, however, that there are user and application scenarios today that already use 
  180. more than 4MB.  Users who already require more than 4MB will continue to require more 
  181. than 4MB with Chicago ù and if they are using more than 4MB, they should see improved 
  182. performance.  But they wonÆt get away with using less memory in the future than they do 
  183. today.  ItÆs an important distinction to maintain. 
  184.  
  185. *    You say Chicago will have a different user interface than Windows and Windows NT.  When 
  186. will that user interface be reflected in the beta versions of Chicago? 
  187. The new user interface will be delivered with the first beta of Chicago, scheduled for March 
  188. 1994. 
  189. *    WonÆt a new user interface mean a lot of retraining for current Windows-based users?  Will 
  190. the advantages of the new user interface be worth the retraining costs? 
  191. The user interface being developed for Chicago will offer dramatic gains in ease of learning 
  192. and ease of use for the broad range of people using PCs today.  Instead of mastering 
  193. different kinds of tools to work with different resources on their computers, users of 
  194. Chicago will be able to browse for and access all resources in a consistent fashion with a 
  195. single tool.  This will be much easier than learning separate applications such as Program 
  196. Manager, File Manager, Print Manager, Control Panel, etc. as users of Windows must do 
  197. today.  A system toolbar that is always accessible will make it much easier to start and 
  198. switch between full-screen tasks.  The implementation of OLE 2.0, with its focus on the 
  199. userÆs document rather than on the tool used to create it, and the direct manipulation of 
  200. data through drag and drop in the user interface, will make working with documents easier 
  201. and more intuitive. 
  202.  
  203.  
  204.  
  205. Current users of Windows will be immediately productive with Chicago and be able to learn 
  206. the new features of the user interface as they work.  ChicagoÆs smart setup technology will 
  207. use the current system settings to present an initial configuration that is familiar for the 
  208. current Windows-based user.  And for corporate customers and individuals who may not 
  209. want to make any user interface changes initially, Chicago will enable them to continue 
  210. running their current Program Manager and File Manager configurations. 
  211. *    What is Plug and Play?  What benefits does Plug and Play provide? 
  212. Plug and Play is a technology jointly developed by PC product vendors that will dramatically 
  213. improve the integration of PC hardware and software.  It allows a PC to adapt itself 
  214. dynamically to its environment; devices can be plugged into or unplugged from a machine, 
  215. without the user having to do anything special ù the machine just works.  Plug and Play is 
  216. a general framework that advances that state of the PC architecture by defining how the 
  217. software communicates with any device connected to the PC.  
  218. Plug and Play technology enables installation and configuration of add-on devices without 
  219. user intervention.  Plug and Play will make it possible for a consumer to turn a standard 
  220. desktop system into a great multimedia machine by just ôpluggingö in a Plug and Play sound 
  221. card and CD-ROM, turning on the system, and ôplayingö a  video clip. 
  222. Plug and Play can enable new system designs that can be dynamically reconfigured.  For 
  223. example, imagine a docking station that enables you to remove the portable system while it 
  224. is still running so that you can take it to a meeting, and the system automatically 
  225. reconfigures to work with a lower-resolution display and adjusts for the absence of the 
  226. network card and large disk drive.  Or imagine an IR-enabled subnotebook that automatically 
  227. recognizes, installs and configures an IR-enabled printer when you walk into the room, so 
  228. your applications are ready to print to that printer. 
  229. Plug and Play can also save development and support costs for the product manufacturer.  
  230. Today, as many as 50 percent of support calls received by operating system and device 
  231. manufacturers are related to installation and configuration of devices.  With Plug and Play, 
  232. device driver development is simplified because device manufacturers can write one driver 
  233. that works across multiple bus types using the Universal Driver Model specified by the Plug 
  234. and Play architecture.  Today, device manufacturers have to include bus-specific code in 
  235. each of their drivers.  With Plug and Play, specific bus configuration data is contained in 
  236. ôbus drivers.ö  Also, operating system preinstallation and configuration are simplified for 
  237. OEMs because Plug and Play devices will automatically install and configure during setup. 
  238.  
  239.  
  240. *    What changes to current hardware and software are required to make Plug and Play a 
  241. reality?  How will vendors figure out how to develop new devices with Plug and Play 
  242. capability? 
  243. First, Plug and Play is compatible with existing systems, so nothing ôbreaksö because of 
  244. Plug and Play.  Plug and Play devices can be brought out over time ù in fact, this is already 
  245. occurring ù and will work with existing systems.   
  246. To deliver all of the above benefits requires changes to devices and drivers, the BIOS, and 
  247. the operating system.  Three fundamental capabilities are required for a system to provide 
  248. Plug and Play functionality: 
  249.     *    A unique identifier for every device on the system 
  250.     *    A procedure for the BIOS and operating system to install and configure that device 
  251.     *    A mechanism for the system and applications to recognize that a configuration 
  252.     change has occurred while the system is running 
  253. All the changes to devices and drivers, the BIOS and the operating system are defined by a 
  254. series of specifications for Plug and Play architecture.  The Plug and Play architecture is an 
  255. open, flexible and cost-effective framework for designing Plug and Play products. 
  256. The Plug and Play architecture was jointly developed by a working group of leading vendors, 
  257. who reviewed design proposals with hundreds of companies in the industry at conferences 
  258. and through online forums.  Plug and Play can be implemented by any operating system 
  259. vendor and any hardware manufacturer.  In addition to Microsoft, IBM has announced 
  260. support for Plug and Play in OS/2*. 
  261. The Plug and Play architecture is flexible, because it provides a framework that works on 
  262. multiple types of bus architectures (ISA, SCSI, PCMCIA, VL, PCI, etc.), and it is extensible 
  263. to future bus designs. 
  264. The Plug and Play architecture is also cost-effective, because it requires little or no 
  265. incremental cost for vendors to implement in their products. 
  266. *    WonÆt it take a long time for these changes to be reflected in products? 
  267. Acceptance of the Plug and Play architecture is widespread, as seen by the rapid progress 
  268. the industry is making in delivering Plug and Play specifications and products. 
  269. Specifications have already been released for ISA, SCSI and PCMCIA devices, and the Plug and 
  270. Play BIOS.  Additional specifications are in process, including PCI, ECP, VL, EISA, Micro 
  271. Channel, and Access.  The first Plug and Play devices were demonstrated at COMDEX/Fall 
  272. 1993, representing a wide range of companies and products.  Intel has released development 
  273. kits that enable device and system vendors to deliver improved configuration capabilities for ISA 
  274. and PCI systems running with Windows 3.1 in a manner that will provide compatibility with 
  275. future Windows operating systems.  Fully Plug and Play-capable systems (including all Plug and 
  276. Play devices and a Plug and Play BIOS) will be available in the first half of 1994.  These 
  277. systems will be able to offer complete Plug and Play functionality when combined with Chicago. 
  278.  
  279.  
  280.  
  281. *    IÆve heard that Chicago implements a 32-bit API.  Is that API different from the 32-bit API 
  282. implemented on Windows NT? 
  283. There is only one 32-bit Windows API, called Win32, with ISVs able to use the API set to 
  284. provide different levels of functionality for Windows 3.1, Chicago and Windows NT.  
  285. Chicago implements a large subset of the functionality of the Win32 API offered on 
  286. Windows NT, and extends the Win32 API in some areas.  These extensions will be delivered 
  287. on Windows NT as soon as possible after the release of Chicago. 
  288. *    If there are different implementations of the Win32 API available on different products in the 
  289. Microsoft operating system product line, does that mean ISVs will have to have separate 
  290. versions of their applications for Windows and Windows NT? 
  291. No.  By following some simple guidelines, ISVs can develop a single executable file that runs 
  292. on Windows 3.x, Chicago and Windows NT.  At the recent Professional DevelopersÆ 
  293. Conference, we provided in-depth technical sessions on the proper way to design 
  294. applications to do so, supplied tools in the SDK to help make such development easier, and 
  295. showed several applications that ran across the entire Windows family.   
  296. *    When will applications be available that exploit Chicago?  WonÆt that take a long time? 
  297. ISVs who are developing 32-bit applications for Windows 3.1 and Windows NT using the 
  298. Win32 API and the guidelines we have provided will have applications that are able to run on 
  299. Chicago immediately.  There are already more than 250 Win32 applications available today, 
  300. and more coming quickly.  Other ISVs will wait until Chicago ships to provide their 32-bit 
  301. applications; usually those applications start coming on-line about 90 days after the 
  302. operating system ships.  Chicago also will support todayÆs 16-bit applications, so users can 
  303. move to Chicago immediately and upgrade their applications as they become available. 
  304. Chicago represents a major market opportunity for ISVs.  Chicago will ship on almost all OEM 
  305. systems soon after it is released, and it will be acquired as an upgrade by a substantial portion 
  306. of the Windows installed base (the installed base will probably number more than 50 million by 
  307. mid-1994).  Customers who purchase new systems and upgrade their operating systems are 
  308. the most active purchasers of new software applications.  As a result, ISVs have a very 
  309. significant business incentive to release versions of their applications that exploit Chicago. 
  310. *    IÆve heard Chicago described as a 32-bit operating system, yet IÆve also heard that portions of 
  311. Chicago are implemented with 16-bit code.  Are both these statements correct? 
  312. Chicago will provide a 32-bit platform for applications by implementing the Win32 API on a 
  313. complete, protect-mode operating system.  Chicago will also run well on mainstream 
  314. Windows platforms (which for a large portion of the Windows installed base is a 4MB 
  315. 80386 system), and Chicago will be compatible with applications and drivers for MS-DOS 
  316. and Windows.  These requirements must be met if Chicago is to meet customer needs and 
  317. provide the volume to make ISVs successful. 
  318.  
  319.  
  320.  
  321. These requirements have driven all the design decisions for Chicago.  The resulting design 
  322. deploys 32-bit code wherever it improves performance without sacrificing application 
  323. compatibility.  The design retains existing 16-bit code where it is required to maintain 
  324. compatibility or where size is a critical issue but has minimal impact on performance.  All of the 
  325. I/O subsystems and device drivers in Chicago, such as networking and file systems, are fully 
  326. 32-bit as are all the memory management and scheduling components (the kernel and virtual 
  327. memory manager).  Many functions provided by the Graphics Device Interface (GDI) have been 
  328. moved to 32-bit code, including the spooler and printing subsystem, the rasterizer, and the 
  329. drawing operations performed by the graphics ôDIBengine.ö  Much of the window management 
  330. code (user) remains 16-bit to retain application compatibility. 
  331. *    If portions of Chicago still remain 16-bit, what happens when a 32-bit application makes a 
  332. function call that is implemented by the 16-bit Chicago component?  DoesnÆt this slow down 
  333. 32-bit applications on Chicago relative to 16-bit applications? 
  334. When Win32-based applications call a 32-bit API that is implemented by a 16-bit component 
  335. of the system, the function call is translated to its 16-bit equivalent for processing by the 
  336. system.  This translation process is referred to as  ôthunking.ö  Although there is some 
  337. overhead associated with a thunking operation, the Chicago thunk layer is very efficient.  
  338. That overhead will be more than offset by the improved efficiency of the linear memory 
  339. addressing scheme used by Win32-based applications.  The overall impact of some 
  340. ôthunkingö code is quite modest vs. all the other work the application and operating system 
  341. have to do.   
  342. For end users, perceptions of application performance are based on a combination of the 
  343. efficiency of the application when executing its own code and the efficiency of the operating 
  344. system code when the application has called an operating system service.  On Chicago 
  345. systems with adequate memory, end users will experience gains in system efficiency when 
  346. running 16-bit applications, and they will experience gains in both system and application 
  347. efficiency when running 32-bit applications. 
  348. *    Will I need new networking software to connect Chicago to my network server? 
  349. Customers will require Chicago to connect to their network servers when Chicago is 
  350. installed, and to offer high-performance, reliable networking functionality.  To meet this 
  351. requirement, Chicago will continue to run existing real-mode networking components.  
  352. However, we expect customers to want to upgrade to the new 32-bit networking 
  353. components provided by Chicago.  Chicago will enhance the open, flexible, high-
  354. performance 32-bit networking architecture offered today with Windows for Workgroups 
  355. 3.11 that enables customers to mix and match networking components.  Chicago will 
  356. support NDIS 2.0, NDIS 3.0 and ODI drivers, and will provide 32-bit NetBEUI, IPX/SPX and 
  357. TCP/IP protocols.  Redirectors for SMB and NCP-based networks will be included.  In 
  358. addition, ChicagoÆs new multiple-provider interface will make it possible for the user to view, 
  359. browse and connect to multiple networks in a consistent fashion. 
  360.  
  361.  
  362. *    What about NetWare*?  Are you working with Novell on NetWare support? 
  363. Customers will require high-performance, reliable NetWare support the day Chicago is released.  
  364. To meet that requirement, Microsoft is developing a 32-bit NCP Redirector that is seamlessly 
  365. integrated with the Chicago user interface, and is encouraging Novell to do the same.  Microsoft 
  366. will offer Novell access to information and assistance to write a Chicago redirector.  Novell 
  367. engineers attended the Win32 Professional DevelopersÆ Conference and have been provided 
  368. access to the Preliminary DeveloperÆs Kit for Chicago.   
  369. With this approach, customers should be able to choose from multiple sources for reliable, 
  370. high-performance NetWare connectivity software when Chicago is released. 
  371. *    Will there be a Chicago server? 
  372. No, not in the sense of a ôserver productö such as Windows NT Advanced Server.  Chicago 
  373. will continue to improve upon the peer server capabilities offered in Windows for 
  374. Workgroups by offering additional features for remote installation, control and 
  375. administration.  These features will make Chicago an even better product for an easy-to-use 
  376. file and print-sharing LAN that is ideally suited as a small-business, small-department or 
  377. remote office network.  Similarly, Windows NT offers peer services as well for the high-end 
  378. desktop.  But for most  server applications, and in the sense that most people ask about a 
  379. ôserver product,ö Windows NT Advanced Server is the Microsoft server product. 
  380. *    I keep hearing rumors that you are working on a portable version of Chicago.  Is this true? 
  381. No, we are not working on a portable version of Chicago.  Windows NT is our portable 
  382. operating system, and itÆs already available on high-end Intel, MIPS*, Alpha and Clipper* 
  383. machines; it will be available on the PowerPC* by mid-1994 and on other high-end 
  384. platforms over time.  There is no reason to make Chicago portable.  Chicago is optimized for 
  385. Intel processors, and much of its internal code is Intel assembler, which puts Chicago at the 
  386. heart of todayÆs low-end and mainstream line.   Portability is important for the new 
  387. generation of high-powered Intel and RISC machines, on which Windows NT runs and for 
  388. which Windows NT has been optimized.  As these new high-end machines become more 
  389. mainstream, which will happen over time, Windows NT will already offer the power, 
  390. security, and reliability that users will demand to exploit these new machines.   
  391. *    What will Chicago do to make the client operating system more manageable? 
  392. A primary goal for the Chicago project is to make Windows less expensive to deploy in a 
  393. corporation.  Chicago will include some specific features and enabling technologies that will 
  394. make it easier for system administrators to install, configure, monitor, maintain and 
  395. troubleshoot their Windows-based desktops. 
  396. Chicago can be set up from a network server and at the desktop can be configured at the 
  397. desktop to run locally or across the network.  In each case, the administrator can establish a 
  398. specific configuration for the installation, selecting from a flexible array of setup 
  399. configuration options.  Chicago desktops require only a floppy drive to start up, and paging 
  400. of components to a swapfile on the network can be disabled to minimize network traffic.   
  401.  
  402.  
  403.  
  404. Once Chicago is installed, administrators will be able to centrally configure desktop settings 
  405. such as file and printer sharing, network access, and passwords.  They can remotely monitor 
  406. Chicago desktops with peer services running to determine what resources are shared, what 
  407. connections have been made, and what files are being used.  Chicago enhances the security 
  408. provided by Windows for Workgroups to include user-level security.  To enable users to access 
  409. their personal groups, applications, and data from any system on the network, Chicago will 
  410. provide user profiles. 
  411. Chicago will also provide the infrastructure for the delivery of enhanced desktop 
  412. management services by third parties. A backup agent will be included with Chicago to 
  413. enable administrators to back up desktop data to a network server. To integrate the desktop 
  414. into SNMP-based enterprise management systems, Chicago will also include a Systems 
  415. Network Management Protocol (SNMP) agent and a Management Information Base (MIB) for 
  416. a number of system resources. The system registry and Plug and Play architecture provide a 
  417. rich store of data about the software and hardware configuration on the desktop, and this 
  418. information can be accessed by system management software using a DCE-compliant 
  419. Remote Procedure Call (RPC) mechanism. 
  420. *    What improvements will Chicago offer for people who use a mobile or remote computer? 
  421. Chicago will provide great support for mobile form-factor devices and will make it easy for 
  422. end users to access the resources of their desktop systems when they are away from their 
  423. offices.  The implementation of Plug and Play in Chicago will support insertion and removal 
  424. of devices such as PCMCIA cards while the operating system is running.  It will also support 
  425. automatic reconfiguration of dockable computers when they are inserted or removed from 
  426. the docking station, without rebooting the system.  An enhanced version of Advanced 
  427. Power Management will further extend battery life.  The services provided by Windows* for 
  428. Pen Computing will be enhanced and incorporated into Chicago, including basic inking and 
  429. rendering support. 
  430. A special focus will be on remote connectivity.  Any Chicago-based machine will be able to 
  431. serve as a Remote Access dial-up server or a remote client for Windows NT Advanced 
  432. Server, Novell NetWare servers or Chicago peer servers.  The same technology will be used 
  433. for serial cable and infrared connections between PCs. The Remote Access architecture will 
  434. be integrated with the Chicago networking architecture by using the same network protocols 
  435. and advanced security features.  Remote Access will support wireless devices and allow 
  436. application developers to make their applications ôslow-link awareö to improve the user 
  437. experience when working on a remote system via modem rather than on a high-bandwidth 
  438. network.  Furthermore, Chicago will provide a simple form of file synchronization and APIs 
  439. for applications to access the file synchronization services to merge changes when both the 
  440. source document and copy have been modified.  
  441. Remote e-mail and Microsoft at Work* fax capability will be included, as in Windows for 
  442. Workgroups 3.11 today. 
  443. *    Will the file synchronization feature in Chicago provide document management capabilities? 
  444. ChicagoÆs file synchronization services are optimized for the needs of the mobile computer 
  445. user who wants to take copies of documents to a remote location and have them be 
  446. automatically synchronized with the source documents.  It is not intended as a replacement 
  447. for sophisticated document management systems. 
  448.  
  449.  
  450.  
  451. ChicagoÆs file synchronization allows customers to identify files that they want to stay up to 
  452. date, to change those files, and to have the files automatically updated when the source file 
  453. is available to the system.  The update is performed by replacing the source file with the 
  454. modified copy at the discretion of the user.  If an application writes a ômerge-handler,ö then 
  455. specific data within the modified and source copies of a file can be merged, to create a new 
  456. updated copy. 
  457. *    You say you have one API with Win32.  Does that mean there will also be just one Windows 
  458. SDK? 
  459. Yes, there will be one Win32 SDK that developers can use to develop 32-bit applications for 
  460. Windows 3.1, Chicago and Windows NT.  In fact, we recently announced a new 
  461. subscription service, the Microsoft Developer Network Level II that provides developers with 
  462. not only the Win32 toolkit, but every system toolkit we offer, on a single CD, updated 
  463. quarterly. 
  464.    
  465. *    What benefits does Chicago offer to developers?  What are you doing to make developing 
  466. Windows-based applications easier? 
  467. The Microsoft Visual Basic* programming system has dramatically streamlined and simplified 
  468. the development of Windows-based applications, and it will be enhanced to support the 
  469. development of 32-bit applications for Chicago.  Microsoft also is enhancing its Visual C++
  470. * development system and Microsoft Foundation Class tools.   
  471. *    Will Chicago include Visual Basic for Applications? 
  472. Visual Basic for Applications will be offered as a separate product. 
  473. *    Will Chicago and Windows NT share the same device drivers? 
  474. Generally not, since Chicago and Windows NT have different device driver models.  However, 
  475. since both products support a modular, layered device driver architecture, there are areas of 
  476. substantial synergy.  For example, SCSI miniport adapters for Windows NT will be binary-
  477. compatible with Chicago, as will printer drivers and NDIS drivers for Windows NT. 
  478.  
  479.  
  480. *    Will WOSA services be included with Chicago? 
  481. WOSA is a general, open framework for implementing multiple back-end services in 
  482. Windows while providing a single front-end interface for end users.  Services in Chicago 
  483. such as messaging and remote network access are designed according to the WOSA 
  484. framework.  Whether or not support for additional WOSA services, such as ODBC support, 
  485. will be shipped with Chicago is a packaging decision that will be made later in the 
  486. development cycle and will be based on customer and business needs.  All the WOSA-
  487. related toolkits are available today to developers through the Microsoft Developer Network 
  488. Level II subscription service. 
  489. ######### 
  490. *1993 Microsoft Corporation.  All rights reserved. 
  491. Microsoft, MS-DOS, Visual Basic and Win32 are registered trademarks and Microsoft at 
  492. Work, Visual C++, Win32s, Windows and Windows NT are trademarks of Microsoft 
  493. Corporation. 
  494. HP is a registered trademark and Omnibook is a trademark of Hewlett-Packard Company. 
  495. Intel is a registered trademark and Pentium is a trademark of Intel Corporation. 
  496. OS/2 is a registered trademark and PowerPC is a trademark of International Business 
  497. Machines Corporation. 
  498. Novell and NetWare are registered trademarks of Novell, Inc. 
  499. MIPS is a registered trademark of MIPS Computer Systems, Inc. 
  500. Clipper is a trademark of Computer Associates International, Inc. 
  501.  
  502. The information contained in this document represents the current view of Microsoft 
  503. Corporation on the issues discussed as of the date of publication.  Because Microsoft must 
  504. respond to changing market conditions, it should not be interpreted to be a commitment on 
  505. the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information 
  506. presented after the date of publication. 
  507.  
  508. This document is for informational purposes only.  MICROSOFT MAKES NO WARRANTIES, 
  509. EXPRESS OR IMPLIED, IN THIS DOCUMENT. 
  510. Chicago Q & A        Page 2 
  511.  
  512. - more - 
  513.  
  514.  
  515.  
  516. - more - 
  517.  
  518.  
  519.